feat: AgentCreateSchema accepts workspace / filesystemScope / fileAccessPolicy - #96

Summary

Three fields defined on the `Agent` type and consumed at runtime — `workspace`, `filesystemScope`, `fileAccessPolicy` — are missing from the Zod `AgentCreateSchema`. `AgentUpdateSchema` derives from it via `.partial()`, so PUT /api/agents/:id silently drops these fields. The runtime behaviors they control (workspace-scoped file ops, fileAccessPolicy enforcement) are therefore unreachable via the public API.

How I found it

Tried to lock a worker agent down to a dedicated workspace via the API:

```
PUT /api/agents/
{
"workspace": "/Users/foo/agent-workspaces/hugo",
"filesystemScope": "workspace",
"fileAccessPolicy": { "blockedPaths": ["/Users/foo/.ssh/**", ...] }
}
```

Endpoint returned 200 with the agent record. But:

```
GET /api/agents/
→ workspace: null, filesystemScope: null, fileAccessPolicy: null
```

Confirmed in the route handler (app/api/agents/\[id\]/route.ts:20-29): `AgentUpdateSchema.safeParse(raw)` strips unknown keys, then the post-parse filter restricts the body to keys present in `parsed.data` — and the missing schema entries mean those keys are absent from `parsed.data` entirely.

End result: the only way to set these fields is to write directly to the `agents` table.

Fix

Add the three fields to `AgentCreateSchema` matching the types in `src/types/agent.ts`:

• `workspace: string | null`
• `filesystemScope: 'workspace' | 'machine' | null`
• `fileAccessPolicy: { allowedPaths?: string[], blockedPaths?: string[] } | null`

No runtime behavior change — just unblocks these fields round-tripping through the API.

Files

• `src/lib/validation/schemas.ts` — 12 lines

Test plan

• Reviewed by inspection — schema-only change.
• Applied locally; PUT now persists all three fields, GET returns them.

🤖 Generated with Claude Code